Many computer systems requiring network communications employ a security infrastructure to ensure that parties such as clients and servers authenticate (e.g, securely identify) each other before one party will process a request from the other party. For example, Kerberos and/or SSL with Public Key Infrastructure (PKI) X.509 certificates may be employed to establish such relationships. With Kerberos, a client may request a ticket to authenticate with a server for a particular service such as a directory service. These services generally may be identified by a service principal name (SPN) in order to authenticate a desired transaction. As system complexities and server responsibilities have increased however, management burdens associated with the authentication process have increased dramatically. Historically, wherein systems may have had only a few names and services to manage and/or authenticate, modern systems may have hundreds of thousands of such names. Some current authentication implementations may construct service principal names from a known service name and a realm. A service principal name may be constructed for example from a name of the type of the service and a Domain Name Server (DNS) host name of a computer providing the service. For example, the printing service for the drafting group of the engineering department in the R&D division of the Example Corporation might be print/draft.eng.rd.example.com@example.com, wherein “print” is the type of the service, the server's name is “draft.eng.rd.example.com”, and the realm name would be “example.com”. Many systems require only a single realm wherein all users and services are part of the same realm. However, in a system wherein multiple trusted realms are required, a client system must first determine what realm a particular user or service is in before requesting a ticket. However, in many circumstances, the users may only know the name of the server, which may not be directly related to the realm name. For example, the printing service described above may be shared by all employees in building 16, regardless of division, so the server it runs on may be named “bldg16.example.com” and the realm may be managed by the MIS department, so it may be named “mis.example.com”. Current authentication mechanisms unfortunately require clients and servers to maintain extensive mappings in order to determine the desired realm. These mechanisms require that each client have detailed configuration information regarding the hosts that are providing such services and corresponding realms. Client side configuration is therefore costly from an administration point of view—especially when there are many realms and computer systems in the environment.
Another problem associated with conventional authentication systems is that services may reside on hosts that may have multiple host names (e.g., multi-homed hosts). Conventionally, each host name would require a distinct name and corresponding key for authentication. As described above, management of potentially thousands of such names and keys is both burdensome and expensive. Still yet another problem associated with conventional authentication systems is that they may not deal securely with replicated services. A replicated service is one wherein many copies of the service run—each on a different server. Each copy may provide essentially the same service (e.g., the data on one service may be slightly out of date compared to another one, but not so much that clients may be affected substantially). Some of the reasons for multiple copies of services are related to robustness and performance. Robustness may be enhanced because if some copies fail, remaining copies may still provide service, although, with somewhat lower performance. Performance may be enhanced, because the number of copies may be increased to handle increased numbers of clients, while attaining similar levels of performance for each client.
In a conventional system (e.g., Kerberos authentication), a domain controller (referred to as a KDC in Kerberos terminology), may provide assurances, that to a client, a non-replicated service is authentic, even if a DNS has been compromised to give an incorrect network address for the host name of the server running a service. However, a replicated service is often located by employing a DNS to resolve the service name to a list of hosts running the service. If the DNS is compromised and caused to give back an incorrect list, yet the hosts in the list are running a different instance of the service, the KDC may not detect the error.
For example, a printing service for an Example Corporation may be named “prt.example.com” and thereby run on servers “p1.example.com” and “p2.example.com”. Generally, a Kerberos client may resolve “prt.example.com” to “p1.example.com” and “p2.example.com”, select a name (e.g., the first one), construct an SPN “print/p1.example.com”, and utilize Kerberos to get a ticket which would authenticate itself to “p1.example.com” and vice-versa. If an unscrupulous employee of Example Corporation were to run a printing service for a small workgroup, however, and the service were to run on the server “pwkgrp.example.com”, security problems are likely to arise. If the employee were to cause the DNS to return “pwkgrp.example.com” as the server running “prt.example.com”, then the client may construct the SPN “print/pwkgrp.example.com”, which Kerberos may then authenticate, and the client may unfortunately print confidential information on the unscrupulous employee's printer.
Currently, there is not an efficient and straightforward way of managing and authenticating system services without substantial configuration, associated administration costs and security concerns. Consequently, there is an unsolved need in the art for authenticating services by mitigating client/server configuration requirements.